COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	This file contains some descriptions of some known bugs which have not
C00003 00003	1. Calling  a parametric procedure whose actual is not in the same file
C00005 00004	2. FOREACH searches with one ELEMENT ANY and one unbound local sometimes
C00007 00005	3. Calling a procedure with an expression where a reference parameter is
C00009 00006	4. There is no way to use a derived set simply within a FOREACH context.
C00010 00007	5. ERASES  sometimes cause havoc within foreaches.
C00012 ENDMK
C⊗;
This file contains some descriptions of some known bugs which have not
been fixed either because it is not known how to fix them or it is
more trouble to fix them than they are worth.

1. Calling  a parametric procedure whose actual is not in the same file
   and is not SIMPLE or an outer block procedure will cause an infinite
   loop in the procedures prologue because the static link cannot be
   calculated by following the current static link.
   E.G.

   Program 1:
   BEGIN "PRG1"
	EXTERNAL PROCEDURE FOO(PROCEDURE BAZ);
	REQUIRE "PRG2" LOAD_MODULE;
	PROCEDURE F1(INTEGER X);
	BEGIN
		PROCEDURE FUBAR;
		BEGIN
			OUTSTR("HI"&CVS(X));
		END;

	        FOO(FUBAR);
	END;
	F1;
   END "PRG1"

   Program 2:
   ENTRY FOO;
   BEGIN "PRG2"
	INTERNAL PROCEDURE FOO(PROCEDURE BAZ);
	BEGIN
		BAZ;
	END;
   END "PRG2"
2. FOREACH searches with one ELEMENT ANY and one unbound local sometimes
   returns duplicates of satisfier.

   E. G. if associative store contains:

		A1⊗O1≡V1
		A1⊗O2≡V1
		A1⊗O3≡V1

	FOREACH X | X⊗ANY ≡ V1 DO
		DATUM(X)←DATUM(X)+1;

   The datum of A1 will be incremented by 3, rather than the 1 which is
   expected. Note that this is different than the duplicate satisfiers
   obtained when a list search containing multiple instances of an item
   is used to bind a local. Note that the semantics of

	FOREACH x | x ε LIST1 ∧ A⊗x≡V DO

   is different from the semantics for

	FOREACH x | A⊗x≡V ∧ x ε LIST1 DO

   as the first allows duplications of "x" while the second does not.
3. Calling a procedure with an expression where a reference parameter is
   required (i. e. when a CORTMP must be allocated such as for all
   FORTRAN procedures) from within a recursive context sometimes fails
   because the CORTMP is remopped too early (before the ISUCAL) and is
   used to save some random accumulator.

   E.G.

   BEGIN
	INTEGER PROCEDURE FOO(REFERENCE INTEGER A,B);
		RETURN(A+B);
	RECURSIVE PROCEDURE MUMBLE;
	BEGIN
		INTEGER A,B;
		A ← 2;
		B ← 3;
		A ← (A+B)+FOO(A+0,B);
	END;
	MUMBLE;
   END;

   This particular case will probably not cause very many difficulties as
   a warning message about passing A+0 by reference is given and most
   people would recompile. However if the procedure FOO were a FORTRAN
   procedure no such message would be emitted and the user would have
   no way of knowing he should suspect his results.
4. There is no way to use a derived set simply within a FOREACH context.
   This at least gives an error message to the user when he compiles a
   construct such as:

	FOREACH x | x ε A⊗B DO

   The problem is that RFS made work for
	FOREACH y | A⊗(A⊗B)≡y DO

   It is very difficult to get it to work both ways.

   The same problem exists with bracketed triples within foreaches.
5. ERASES  sometimes cause havoc within foreaches.
	If an association is erased which is pointed to by some SCB
	that pointer should be altered in some way to indicate it
	is no longer valid so that at least an error message can be given
	This is very difficult to handle efficiently because it entails
	a search of every active SCB and in the majority of cases
	this search is for naught. Also some SCB's are hidden on the
	stack such as within make and erase breakpoints.

	Processes add even more hair in finding all the SCB's

6. Changing a set or list variable which is being searched within some encompassing
	FOREACH (dynamic) can sometimes cause the FOREACH interpreter to
	end up searching the free-storage list.


	This can occur when we REMOVE the next item that would have been
	returned, or when we change the value of the variable by assignment.
	
	This is almost impossible to detect without extreme overhead  in
	the set and list assignment code to check each node in the old value
	of the set to see if it is pointed to by some SCB.

	We can always get around this by making a temp set by concatenating a
	nil list or unioning a phi set to copy the list or set variable.